|
|
|
|
|
|
|
The class SomeWorkgroupProxy is the workgroup class for the example. However, notice the suffix Proxy. I use this suffix because the actual workgroup component that manages and enforces rules related to a workgroup will typically be housed on a workgroup server. Nonetheless, for simpler systems, you could have these workgroup proxy objects on every client machine at a small client site. Taken together, they would represent a virtual workgroup server without the need for a dedicated, centralized, physical server. Of course, this means that you have to have some map (such as a component diagram) that reminds you of the location and responsibilities of each workgroup proxy. |
|
|
|
|
|
|
|
|
For a role class, some of the same members are similar to those of other form controllers. Each role class could implement a showTask() method that presents the task to the user based on the value of the CurrTaskID of the Process object. For example, a role could display a Visual Basic form that is particular to a specific role performed by a user. Given this coupling between a role and the form for which a role is responsible, you could add code to disable/enable or to change the visibility of controls on common forms that do not apply to other roles. This makes maintaining the code to control the accessibility of GUI controls much easier. In the example, the WorkerRole class will have a collection of forms, indexed by the value of CurrTaskID of the Process object and the Enum, eTasks. The ManagerRole class does not need such a collection, but for consistency sake, let's incorporate one. |
|
|
|
|
|
|
|
|
On each form will undoubtedly be GUI controls that, upon interaction with the user, trigger some meaningful even that needs further processing. The most common event you're likely to process is a control's click event. Thus, each form controller tends to have a method, clickedControl(), that is an abstract type of method that processes each specialized GUI control click event. |
|
|
|
|
|
|
|
|
For each form you also would want to display some caption that represents the task being performed by the user. The string array arrTaskName would hold the name of each task performed by the role. You'll use the eTasks Enum to identify each item in the array. Listing 13.1 shows the three Enums in the module, modWorkflow. |
|
|
|
|
|
|
|
|
For the TaskName property of Role1, the values are Do Task1 and Do Task2. There are three empty forms, which simply represent the three tasks. Each has a command button named cmdDone and captioned Done. The startup object for the project is Sub Main, which is in the module, modMain. Due to the length of the code, you can find it on the CD as part of the Second Bank of Carrollton application. |
|
|
|
|
|
|
|
|
By no means is the list of classes in Table 13.1 exhaustive of the typically complex workgroup/workflow system. However, you can certainly use it as a starting point for developing such a system. If your environment is not complex at all, you can use these |
|
|
|
|
|